<!doctype html>
<html>
	<head>
		<meta charset="utf-8">
		<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

		<title>reveal.js</title>

		<link rel="stylesheet" href="css/reveal.css">
		<link rel="stylesheet" href="css/theme/black.css">

		<!-- Theme used for syntax highlighting of code -->
		<link rel="stylesheet" href="lib/css/zenburn.css">

		<!-- Printing and PDF exports -->
		<script>
			var link = document.createElement( 'link' );
			link.rel = 'stylesheet';
			link.type = 'text/css';
			link.href = window.location.search.match( /print-pdf/gi ) ? 'css/print/pdf.css' : 'css/print/paper.css';
			document.getElementsByTagName( 'head' )[0].appendChild( link );
		</script>
	</head>
	<body>
		<div class="reveal">
			<div class="slides">
				<section data-markdown>
                    # 创建网络
                </section>

                <section data-markdown>
                    ![创建网络](images/创建网络.png)
                </section>

                <section data-markdown>
                    - 当命令启动时，网络就形成了。在我们的示例网络N中，由单个节点O4组成的排序服务根据网络配置NC4进行配置，NC4赋予组织R4管理权限。在网络级，证书颁发机构CA4用于向R4组织的管理员和网络节点分配身份
                    - 我们可以看到，定义网络N的第一件事是排序服务O4。将排序服务看作是网络的初始管理点是很有帮助的。如前所述，O4最初是由组织R4中的管理员配置和启动的，并驻留在R4中。配置NC4包含描述网络初始管理功能集的策略。最初NC4被设置为在网络中只对R4授予权限。这将会改变，稍后我们将看到，但是目前R4是网络的唯一成员。
                </section>

                <section data-markdown>
                    # 证书颁发机构（Certificate Authorities）
                </section>

                <section data-markdown>
                    - 你还可以看到一个证书颁发机构CA4，它用于向管理员和网络节点颁发证书。CA4在我们的网络中扮演着关键角色，因为它分发了X.509证书，可以用来识别属于组织R4的组件。CA颁发的证书也可以用来签署交易，以表明某个组织背书交易结果——这是交易结果被账本接受的前提条件。让我们更详细地研究一下CA的这两个方面。
                </section>

                <section data-markdown>
                    - 首先，区块链网络的不同组件使用证书相互标识自己来自某个特定组织。这就是为什么支持区块链网络的CA通常不止一个——不同的组织经常使用不同的CA。我们将在网络中使用4个CA；每个组织一个。CA是那么重要，实际上Hyperledger Fabric为你提供了一个内置的(称为Fabric-CA)CA来帮助你开始工作，尽管在实践中，组织会选择使用自己的CA。
                </section>

                <section data-markdown>
                    - 证书到成员组织的映射是通过一个名为成员服务提供者（MSP）.的结构实现的。网络配置NC4使用一个命名的MSP来标识CA4分发的证书的属性，CA4将证书持有者与组织R4关联起来。然后，NC4可以在策略中使用这个MSP名称来从R4授予参与者对网络资源的特定权利。这种策略的一个示例是识别R4中的管理员，他们可以向网络添加新的成员组织。我们不会在这些图上显示MSP，因为它们会把图弄乱，但是它们非常重要。
                </section>

                <section data-markdown>
                    - 其次，稍后我们将看到CA颁发的证书是如何在交易发生和验证过程的核心。具体来说，X.509证书用于客户端应用程序交易提议和智能合约交易响应来对交易进行数字签名。随后，托管帐本副本的网络节点在接受交易进账本之前验证交易签名是有效的。
                    - 让我们回顾一下示例区块链网络的基本结构。有一个资源，网络N，由证书颁发机构CA4定义的一组用户访问，这些用户对网络N中的资源拥有一组权限，由网络配置NC4中包含的策略描述。所有这些都在配置和启动排序服务节点O4时实现。
                </section>

                <section data-markdown>
                    # 增加网络管理员
                </section>

                <section data-markdown>
                    - NC4最初配置为只允许R4用户对网络进行管理。在下一个阶段，我们将允许组织R1的用户管理网络。让我们看看网络是如何进化的:
                </section>

                <section data-markdown>
                    ![增加网络管理员](images/增加网络管理员.png)
                </section>

                <section data-markdown>
                    - 组织R4更新网络配置，使组织R1也成为管理员。在此之后，R1和R4对网络配置拥有同等的权利。
                    - 我们看到一个新的组织R1作为管理员添加——R1和R4现在在网络上拥有平等的权利。我们还可以看到，已经添加了证书颁发机构CA1——它可以用来标识来自R1组织的用户。在此之后，R1和R4的用户都可以管理网络。
                </section>

                <section data-markdown>
                    - 尽管排序节点O4在R4的基础设施上运行，但R1共享了对其的管理权限，只要它能够获得网络访问权。这意味着R1或R4可以更新网络配置NC4，使R2组织成为子网运作。这样，即使R4正在运行排序服务，并且R1对其拥有完全的管理权限，R2也有受限的权限来创建新的联盟。
                </section>

                <section data-markdown>
                    - 在最简单的形式中，排序服务是网络中是单个节点，你可以在示例中看到这一点。排序服务通常是多节点的，可以配置为在不同的组织中有不同的节点。例如，我们可以在R4中运行O4，并将其连接到组织R1中的另一个排序节点O2。这样，我们就会有一个多站点、多组织的管理结构。
                    - 现在只需将排序服务看作是一个管理点，它为不同的组织提供对网络的控制访问。
                </section>

                <section data-markdown>
                    # 定义一个联盟
                </section>

                <section data-markdown>
                    - 虽然网络现在可以由R1和R4管理，但是几乎没有什么可以做的。我们需要做的第一件事是定义一个联盟。这个词字面上的意思是“拥有共同命运的群体”，所以它是区块链网络中一组组织的合适选择。
                </section>

                <section data-markdown>
                    ![定义一个联盟](images/定义一个联盟.png)
                </section>

                <section data-markdown>
                    - 网络管理员定义一个联盟X1，其中包含两个成员，即组织R1和R2。该联盟定义存储在网络配置NC4中，将在网络开发的下一个阶段使用。CA1和CA2分别是这俩组织的证书颁发机构。
                    - 由于NC4已经配置好，只有R1或R4可以创建新的联盟。这个图显示了添加了一个新联盟X1，它定义R1和R2为其组成组织。我们还可以看到，添加CA2用来识别R2中的用户。请注意，一个联盟可以有任意数量的组织成员——我们刚刚展示了两个，因为它是最简单的配置。
                </section>

                <section data-markdown>
                    - 为什么联盟很重要?我们可以看到，一个联盟定义了网络中的一组组织，它们需要相互进行交易——在本例中是R1和R2。如果组织有一个共同的目标，那么把它们组在一起是很有意义的，这就是正在发生的事情。
                    - 网络虽然是由单个组织发起的，但现在由更大的组织群控制。我们可以这样开始，R1、R2、R4共享控制，但是这种构建更容易理解。
                    - 现在，我们将使用联盟 X1来创建Hyperledger Fabric区块链的一个非常重要的部分——通道。
                </section>

                <section data-markdown>
                    # 为联盟创建通道
                </section>

                <section data-markdown>
                    - 因此，让我们创建Fabric区块链网络的关键部分——通道。通道是一个主要的通信机制，通过它，一个联盟的成员可以互相通信。网络中可以有多个通道，但现在，我们先从一个通道开始。
                    - 让我们看看第一个通道是如何添加到网络的:
                </section>

                <section data-markdown>
                    ![为联盟创建通道](images/为联盟创建通道.png)
                </section>

                <section data-markdown>
                    - 使用联盟X1为R1和R2创建了通道C1。通道由通道配置CC1来管理，完全独立于网络配置。CC1由R1和R2管理，它们对C1拥有同等的权利。R4在CC1中没有任何权利。
                    - 通道C1为联盟X1提供了一个私有通信机制。我们可以看到通道C1已经连接到排序服务O4，但是没有其他连接到它。在网络开发的下一个阶段，我们将连接诸如客户端应用程序和对等节点之类的组件。但在当前，通道为未来的连通性提供了潜力。
                </section>

                <section data-markdown>
                    - 尽管通道C1是网络N的一部分，但它与网络N有很大区别。还要注意，组织R3和R4不在这个通道中——它用于R1和R2之间的交易处理。在前面的步骤中，我们看到了R4如何授予R1权限来创建新的联盟。值得一提的是，R4还允许R1创建通道！在这个图中，可能是组织R1或R4创建了通道C1。同样，请注意，一个通道可以有任意数量的组织连接到它——我们已经展示了两个，因为这是最简单的配置。
                </section>

                <section data-markdown>
                    - 再次注意，通道C1对于网络配置NC4有一个完全独立的配置CC1。CC1包含管理R1和R2在通道C1上的权限的策略——正如我们所见，R3和R4在这个通道中没有许可。R3和R4只有被R1或R2添加到通道配置CC1的适当策略中才能与C1交互。例如，定义谁可以向通道添加新组织。特别要注意的是，R4不能将自己添加到通道C1中——它必须并且只能由R1或R2授权。
                </section>

                <section data-markdown>
                    - 为什么通道如此重要？通道是有用的，因为它们为联盟成员之间的私有通信和私有数据提供了一种机制。通道提供对于其他通道和网络的隐私。Hyperledger Fabric在这方面非常强大，因为它允许组织们共享基础架构并同时保持私有。这里没有矛盾——网络中的不同联盟需要不同的信息和流程来进行适当地共享，而通道提供了一种有效的机制来实现这一点。通道提供了基础设施的高效共享，同时维护了数据和通信的隐私。
                </section>

                <section data-markdown>
                    - 我们还可以看到，一旦创建了一个通道，它就真正感觉“脱离了网络”。只有在通道配置中显式指定的组织才能控制它，从现在到将来。同样，从现在开始对网络配置NC4的任何更新都不会对通道配置CC1产生直接影响；例如，如果联盟X1被更改，它将不会影响通道C1的成员。因此，通道是有用的，因为它们允许组成通道的组织之间进行私有通信。此外，通道中的数据与网络的其他部分（包括其他通道）完全隔离。
                </section>

                <section data-markdown>
                    - 另外，还定义了一个特殊的系统通道供排序服务使用。它的工作方式与常规通道完全相同，由于这个原因有时也被称为应用程序通道。我们通常不需要担心这个通道，但是我们会在本主题稍后讨论它。
                </section>

                <section data-markdown>
                    # 对等节点和账本（Peers and Ledgers）
                </section>

                <section data-markdown>
                    - 现在让我们开始使用通道将区块链网络和组织组件连接起来。在网络开发的下一个阶段，我们可以看到我们的网络N刚刚获得了两个新的组件，即一个对等节点P1和一个账本实例L1。
                </section>

                <section data-markdown>
                    ![对等节点和账本](images/对等节点和账本.png)
                </section>

                <section data-markdown>
                    - 对等节点P1已加入通道C1。P1物理上拥有一个账本L1的副本。P1和O4可以通过通道C1进行通信。
                    - 对等节点是承载区块链帐本副本的网络组件！最后，我们开始看到一些可识别的区块链组件！P1在网络上的目的纯粹是为了给其他人提供一个L1的副本。我们可以将L1看作被物理托管到P1上，但逻辑托管到C1上。当我们向通道中添加更多的对等点时，我们会更清楚地看到这个想法。
                </section>

                <section data-markdown>
                    - P1配置的一个关键部分是CA1发出的X.509标识，该标识将P1与组织R1相关联。一旦P1启动，它就可以使用排序节点O4来加入通道C1。当O4接收到这个加入请求时，它使用通道配置CC1来确定P1在这个通道上的许可。例如，CC1决定P1是否可以读写L1信息。
                    - 请注意，拥有对等节点的组织是如何将对等节点加入到通道的，尽管我们只添加了一个对等节点，但我们将了解如何在网络中的多个通道上有多个对等节点。稍后我们将看到对等节点可以扮演的不同角色。
                </section>

                <section data-markdown>
                    # 应用程序和智能合约链代码
                </section>

                <section data-markdown>
                    - 既然通道C1上有了一个帐本，我们就可以开始连接客户端应用程序去使用由帐本的负载工具对等节点提供的一些服务！
                    - 注意网络如何成长：
                </section>

                <section data-markdown>
                    ![应用程序和智能合约链代码](images/应用程序和智能合约链代码.png)
                </section>

                <section data-markdown>
                    - P1上安装了智能合约S5。组织R1中的客户端应用程序A1可以通过对等节点P1使用S5访问帐本。A1、P1、O4都已加入到通道C1，即都可以使用该频道提供的通信设施。
                </section>

                <section data-markdown>
                    - 在网络开发的下一个阶段，我们可以看到客端应用程序A1可以使用通道C1连接到特定的网络资源——在这种情况下A1可以连接到对等节点P1和排序节点O4。同样，请查看通道对于网络和组织组件之间的通信是如何起中心作用的。与对等节点和排序节点一样，客户端应用程序将具有与组织相关联的标识。在我们的示例中，客户端应用程序A1与组织R1相关联;尽管它在Fabric区块链网络之外，它通过通道C1连接到网络。
                </section>

                <section data-markdown>
                    - 现在看来A1可以通过P1直接访问帐本L1，但实际上，所有的访问都是通过一个名为智能合约链代码S5的特殊程序来管理的。可以认为S5定义了所有对帐本的通用访问模式；S5提供了一组定义良好的方法来查询或更新帐本L1。简而言之，客户端应用程序A1必须通过智能合约S5才能得到L1！
                </section>

                <section data-markdown>
                    - 智能合约链代码可以由每个组织中的应用程序开发人员创建，以实现由联盟成员共享的业务流程。智能合约用于帮助生成交易，这些交易随后可以分发到网络中的每个节点。我们稍后会讨论这个观点；网络越大，就越容易理解。现在，要了解到的重要事情是，要达到这一点，必须对智能合约执行两个操作；它必须已经被安装，然后被实例化。
                </section>

                <section data-markdown>
                    # 安装智能合约
                </section>

                <section data-markdown>
                    - 在开发了智能合约S5之后，组织R1中的管理员必须将其安装到对等节点P1上。这是一个直接了当的操作；之后，P1有了S5全面的知识。具体来说，P1可以看到S5的实现逻辑——它用来访问帐本L1的程序代码。我们将其与S5 接口进行对比，S5接口仅描述了S5的输入和输出，而不关心其实现。
                    - 当一个组织在一个通道中有多个对等节点时，可以选择安装智能合约的对等节点;不需要在每个对等节点上都安装智能合约。
                </section>

                <section data-markdown>
                    # 实例化智能合约(peer chaincode instantiate)
                </section>

                <section data-markdown>
                    - 但是，仅仅因为P1安装了S5，连接到C1通道的其他组件都不知道;它必须首先在通道C1上实例化。在我们的示例中，只有一个对等节点P1，组织R1中的管理员必须使用P1在通道C1上实例化S5。实例化之后，通道C1上的每个组件都知道S5的存在；在我们的示例中，这意味着S5现在可以由客户UMD应用程序A1调用！
                </section>

                <section data-markdown>
                    - 注意，尽管通道上的每个组件现在都可以访问S5，但是它们不能看到它的程序逻辑。对于安装它的节点来说仍然是私有的；在我们的例子中是P1。从概念上讲，这意味着实例化的是智能合约接口，而不是安装的智能合约实现。强化这个观点；安装智能合约显示了我们如何把它物理托管到对等节点上，而实例化智能合约显示了我们如何认为它由通道逻辑托管。
                </section>

                <section data-markdown>
                    # 背书策略
                </section>

                <section data-markdown>
                    - 在实例化时提供的最重要的附加信息是背书策略。它描述了哪些组织必须批准交易才能被其他组织接受到他们的帐本副本上。在我们的样例网络中，交易只有在R1或R2背书的情况下才能被接收到L1分类账。
                    - 实例化行为将背书策略放在通道配置CC1中；它允许通道的任何成员访问它。
                </section>

                <section data-markdown>
                    # 调用智能合约(peer chaincode invoke)
                </section>

                <section data-markdown>
                    - 一旦在对等节点上安装了智能合约并在通道上实例化，客户端应用程序就可以调用。客户端应用程序通过将交易提议发送给智能合约背书策略指定的组织所拥有的对等点来实现这一点。交易提议充当智能合约的输入，智能合约使用交易提议来生成经过背书的交易响应，由对等节点返回给客户端应用程序。
                </section>

                <section data-markdown>
                    - 这些交易响应与交易提议打包在一起，形成一个已充分背书的交易，可以分发到整个网络。稍后我们将更详细地了解这一点，这足以理解应用程序如何调用智能合约来生成已背书的事务。
                    - 在网络开发的这个阶段，我们可以看到组织R1完全参与了网络。它的应用程序(从A1开始)可以通过智能合约S5访问帐本L1，生成由R1进行背书的交易，并因此被帐接受，因为它们符合背书政策。
                </section>

                <section data-markdown>
                    # 完整网络
                </section>

                <section data-markdown>
                    - 回想一下，我们的目标是为联盟X1 -组织R1和R2创建一个通道。在网络开发的下一个阶段，组织R2将其基础设施添加到网络中。
                    - 让我们看看网络是如何进化的:
                </section>

                <section data-markdown>
                    ![完整网络](images/完整网络.png)
                </section>

                <section data-markdown>
                    - 通过增加组织R2中的基础设施，网络得到了成长。具体来说，R2添加了对等节点P2，其中包含一个帐本L1副本和链代码S5。P2也加入了通道C1，应用程序A2也是如此。A2和P2使用来自CA2的证书进行标识。所有这些都意味着，应用程序A1和A2都可以使用对等节点P1或P2在C1上调用S5。
                </section>

                <section data-markdown>
                    - 我们可以看到组织R2在通道C1上添加了对等节点P2。P2还包含了帐本L1的副本和智能合约S5。我们可以看到R2还添加了客户端应用程序A2，可以通过通道C1连接到网络。为了实现这一点，组织R2中的管理员创建了对等节点P2并将其连接到通道C1，方法与R1中的管理员相同。
                    - 我们已经创建了我们的第一个运营网络！在网络开发的这个阶段，我们有一个组织R1和R2可以完全相互交易的通道。具体来说，这意味着应用程序A1和A2可以在通道C1上使用智能合约S5和账本L1生成交易。
                </section>

                <section data-markdown>
                    # 生成和接受交易
                </section>

                <section data-markdown>
                    - 与总是拥有帐本副本的对等节点不同，我们看到有两种不同类型的对等节点；有些拥有智能合约，有些没有。在我们的网络中，每个对等点都承载一个智能合约的副本，但是在更大的网络中，将会有更多的对等节点不承载智能合约的副本。对等节点只有安装了智能合约才能运行它，但是它可以通过连接到通道来了解智能合约的接口。
                </section>

                <section data-markdown>
                    - 我们不应该认为没有安装智能合约的对等节点在某种程度上是劣等的。更确切地说，具有智能合约的对等节点具有一种特殊的能力——帮助生成交易。请注意，所有对等节点都可以验证，然后接受或拒绝交易到它们的帐本L1副本上。但是，只有安装了智能合约的对等节点才能参与交易背书的过程，这对于生成有效交易至关重要。
                </section>

                <section data-markdown>
                    - 在这个主题中，我们不需要担心交易是如何生成、分发和接受的确切细节——只要知道我们有一个区块链网络，组织R1和R2可以将信息和流程共享为账本已捕获的交易，就足够了。我们在其他主题将学习更多关于交易，账本，智能合约的内容。
                </section>

                <section data-markdown>
                    # 对等节点类型
                </section>

                <section data-markdown>
                    - 在Hyperledger Fabric中，尽管所有对等节点都是相同的，但是它们可以根据网络的配置来承担多个角色。我们现在对典型的网络拓扑有了足够的了解，可以描述这些角色。
                </section>

                <section data-markdown>
                    - 提交节点。通道中的每个对等节点都是提交对等节点。它接收生成交易的区块，这些交易在作为添加操作提交到对等节点的帐本副本之前经过验证。
                    - 背书节点。如果安装了智能合约，每个拥有智能合约的对等节点都可以成为背书节点。然而，要真正成为背书节点，节点上的智能合约必须由客户端应用程序使用，以生成数字签名的交易响应。“背书节点”一词明确提到了这一事实。
                </section>

                <section data-markdown>
                    - 智能合约的背书策略标识了组织，其节点应该在生成的交易被接受到提交节点的帐本副本之前对其进行数字签名。
                    - 这有两种主要的节点类型；还可以扮演另外两个角色:
                </section>
                <section data-markdown>
                    - 领导节点。当一个组织在一个通道中有多个节点时，领导节点是负责将交易从排序节点分发到组织中其他的提交节点。节点可以选择参与静态或动态的领导选择。
                </section>

                <section data-markdown>
                    - 因此从领导的角度考虑两组节点是很有帮助的——有静态领导选择的节点和有动态领导选择的节点。对于静态集合，可以将零或多个节点配置为leader。对于动态集合，一个节点将被该集合选举为领导者。此外，在动态集合中，如果领导节点故障，剩下的节点将重新选举一个领导节点。
                    - 这意味着组织可以有一个或多个连接到排序服务的领导节点。这有助于提高处理大量交易的大型网络的弹性和可伸缩性。
                </section>
                
                <section data-markdown>
                    - 锚节点。如果一个节点需要与另一个组织中的节点通信，那么它可以使用为该组织在通道配置中定义的一个锚节点。组织可以为其定义零个或多个(anchor peer)锚节点，而锚节点可以帮助处理许多不同的跨组织通信场景。
                    - 请注意，一个节点可以同时是一个提交节点、背书节点、领导节点和锚节点！只有锚节点是可选的——出于所有实际目的，总是会有一个领导节点，并且至少有一个背书节点，至少有一个提交节点。
                </section>

                <section data-markdown>
                    # 只安装不实例化
                </section>

                <section data-markdown>
                    - 与组织R1类似，组织R2必须在其对等节点P2上安装智能合约S5。这是显而易见的——如果应用程序A1或A2希望在对等节点P2上使用S5来生成交易，那么它必须首先存在；安装是这种机制。此时，对等节点P2具有智能合约和帐本的物理副本；与P1一样，它可以在其帐本L1副本上生成并接受交易。
                </section>

                <section data-markdown>
                    - 然而，与组织R1相比，组织R2不需要在通道C1上实例化智能合约S5。这是因为S5已经由组织R1在通道上实例化了。实例化只需要发生一次；随后加入通道的任何节点都知道该通道可以使用智能合约S5。这反映了帐本L1和智能合约在对等节点上以物理方式存在，在通道上以逻辑方式存在的事实；R2只是向网络中添加了另一个L1和S5的物理实例。
                </section>

                <section data-markdown>
                    - 在我们的网络中，我们可以看到通道C1连接了两个客户端应用程序、两个对等节点和一个排序服务。因为只有一个通道，所以只有一个逻辑帐本与这些组件交互。对等节点P1和P2具有相同的帐本L1副本。智能合约S5的副本通常使用相同的编程语言实现，但如果不是这样，它们必须在语义上是等价的。
                </section>

                <section data-markdown>
                    - 我们可以看到，仔细地在网络中添加对等节点可以帮助提高吞吐量、稳定性和恢复能力。例如，网络中更多的对等节点将允许更多的应用程序连接到它;组织中的多个对等节点将在计划或计划外停机的情况下提供额外的弹性。
                </section>

                <section data-markdown>
                    - 这一切都意味着配置精细的拓扑来支持各种各样的操作目标是可能的——一个网络可以达到多大在理论上没有限制。此外，单个组织内的对等节点有效地发现和相互通信的技术机制——流言协议——将容纳大量的对等节点以支持这种拓扑。
                    - 仔细地使用网络和通道策略，即使是大型网络也可以得到良好的管理。组织可以自由地向网络添加对等节点，只要它们符合网络约定的策略。网络和通道策略创造了自治和控制之间的平衡，这是分散式网络的特征。
                </section>

                <section data-markdown>
                    # 简化视觉词汇
                </section>

                <section data-markdown>
                    - 现在我们将简化用于表示样例区块链网络的视觉词汇。随着网络规模的增长，最初用来帮助我们理解频道的线路将变得很麻烦。想象一下，如果我们添加另一个对等节点或客户端应用程序或另一个通道，我们的图表会有多复杂?
                </section>

                <section data-markdown>
                    - 这就是我们接下来要做的，在我们做之前，我们先简化一下视觉词汇。下面是我们迄今为止开发的网络的简化表示:
                </section>

                <section data-markdown>
                    ![简化视觉词汇](images/简化视觉词汇.png)
                </section>

                <section data-markdown>
                    - 该图显示了网络N中与通道C1相关的事实如下:客户端应用程序A1和A2可以使用通道C1与对等端P1和P2，以及排序节点 O4通信。对等节点P1和P2可以使用通道C1的通信服务。排序服务O4可以利用通道C1的通信服务。通道配置CC1应用于通道C1。
                    - 注意，通过将通道线替换为连接点，网络图得到了简化，如图中蓝色圆圈所示，其中包含通道号。没有信息丢失。这种表示更容易扩展，因为它消除了交叉线。这使我们能够更清楚地表示更大的网络。我们通过关注组件和通道之间的连接点而不是通道本身来实现这种简化。
                </section>

                <section data-markdown>
                    # 增加另一个联盟定义
                </section>

                <section data-markdown>
                    - 在网络开发的下一个阶段，我们将介绍组织R3。我们将给组织R2和R3一个单独的应用通道，允许它们彼此进行交易。这个应用通道将完全独立于前面定义的通道，因此R2和R3的交易能保持私有。
                    - 让我们回到网络级别，为R2和R3定义一个新的联盟X2:
                </section>

                <section data-markdown>
                    ![增加另一个联盟定义](images/增加另一个联盟定义.png)
                </section>

                <section data-markdown>
                    - 来自组织R1或R4的网络管理员添加了一个新的联盟定义X2，其中包括组织R2和R3。这将用于定义X2的新通道。
                    - 注意，网络现在已经定义了两个联盟：组织R1、R2的X1和组织R2、R3的X2。为了能够创建R2和R3的新通道，引入了联盟X2。
                </section>

                <section data-markdown>
                    - 新通道只能由网络配置策略NC4中明确指定的具有适当权限（即R1或R4）的组织来创建。这是一个策略的例子，该策略将能够在网络级别管理资源的组织与能够在通道级别管理资源的组织区分开。看到这些政策在起作用帮助我们理解为什么Hyperledger Fabric有一个精细的分层策略结构。
                    - 在实践中，联盟X2被添加到网络配置NC4中。我们将在文档的其他部分讨论此操作的确切机制。
                </section>

                <section data-markdown>
                    # 增加一个新通道
                </section>

                <section data-markdown>
                    - 现在让我们使用这个新的联盟X2来创建一个新的通道C2。为了加强你对更简单的通道符号的理解，我们使用了两种视觉样式——通道C1用蓝色圆形端点表示，而通道C2用红色连接线表示：
                </section>

                <section data-markdown>
                    ![增加一个新通道](images/增加一个新通道.png)
                </section>

                <section data-markdown>
                    - 使用联盟X2为R2和R3创建了一个新的通道C2。该通道有一个通道配置CC2，完全独立于网络配置NC4和通道配置CC1。通道C2由R2和R3管理，R2和R3对C2享有同等的权利，这是由CC2中的策略定义的。R1和R4在CC2中没有定义任何权限。
                </section>

                <section data-markdown>
                    - 通道C2为联盟X2提供了一种私有通信机制。再次注意组织们如何在一个联盟中联合，是创建了渠道。通道配置CC2现在包含管理通道资源的策略，将通道C2的管理权限分配给组织R2和R3。它只由R2和R3管理；R1和R4在通道C2中没有力量。例如，随后可以更新通道配置CC2，以增加组织来支持网络增长，但这只能由R2或R3来完成。
                </section>

                <section data-markdown>
                    - 注意，通道配置CC1和CC2是如何保持彼此完全独立、并且完全独立于网络配置NC4的。我们再一次看到Hyperledger Fabric网络的分散式本性；通道C2一旦创建，就由组织R2和R3独立于其他网络元素管理。通道策略始终保持相互独立，并且只能由在通道中已授权可以这样做的组织才能进行更改。
                </section>

                <section data-markdown>
                    - 随着网络和通道的进化，网络和通道配置也会发生变化。这过程是通过受控的方式完成的——这要涉及到捕获对这些配置的更改的配置交易。每次配置更改都会生成一个新的配置交易区块，本主题稍后，我们将看到如何验证和接受这些区块来分别创建更新的网络和通道配置。
                </section>

                <section data-markdown>
                    # 网络和通道配置
                </section>

                <section data-markdown>
                    - 在我们的样例网络中，我们看到了网络和通道配置的重要性。这些配置非常重要，因为它们封装了网络成员协商一致的策略，为控制对网络资源的访问提供了共享引用。网络和通道配置还包含关于网络和通道组成的事实，例如联盟及其组织的名称。
                </section>

                <section data-markdown>
                    - 例如，当网络刚形成时使用排序服务节点O4，其行为由网络配置NC4管理。NC4的初始配置只包含允许组织R4管理网络资源的策略。NC4随后被更新，允许R1管理网络资源。一旦进行了此更改，连接到O4的组织R1或R4的任何管理员都将拥有网络管理权，因为这是网络配置NC4中的策略所允许的。在内部，排序服务中的每个节点记录网络配置中的每个通道，这样，在网络级别上就有了一份每个创建的通道的记录。
                </section>

                <section data-markdown>
                    - 这意味着，尽管排序服务节点O4是创建联盟X1、X2以及通道C1、C2的参与者，但是网络的智能包含在O4所服从的网络配置NC4中。只要O4表现得像一个好的参与者，并且在处理网络资源时正确地实现NC4中定义的策略，我们的网络就会表现得像所有组织都同意的那样。在许多方面，NC4可以被认为比O4更重要，因为它最终控制网络访问。
                    - 对于对等节点，同样的原则适用于通道配置。在我们的网络中，P1和P2也是很好的参与者。当对等节点P1和P2与客户端应用程序A1或A2交互时，它们各自使用通道配置CC1中定义的策略来控制对通道C1资源的访问。
                </section>

                <section data-markdown>
                    - 例如，如果A1希望访问对等节点P1或P2上的智能合约链代码S5，则每个对等节点使用其CC1副本来确定A1可以执行的操作。例如，A1可以根据CC1中定义的策略从帐本L1中读取或写入数据。稍后我们将在通道及其通道配置CC2中看到相同的参与者模式。同样，我们可以看到，虽然对等节点和应用程序是网络中的关键角色，但它们在通道中的行为更多地取决于通道配置策略，而不是其他因素。
                </section>

                <section data-markdown>
                    - 最后，了解如何物理地实现网络和通道配置是很有帮助的。我们可以看到，网络和通道配置在逻辑上是单一的——网络有一个，每个通道有一个。这是很重要的;访问网络或通道的每个组件都必须对授予不同组织的权限有共同的理解。
                </section>

                <section data-markdown>
                    - 即使在逻辑上有一个单独的配置，它实际上被构成网络或通道的每个节点复制并保持一致。例如，在我们的网络对等节点P1和P2都有一个通道配置CC1的副本，当网络彻底完成时，对等节点P2和P3都有一个通道配置CC2的副本。类似地，排序服务节点O4具有网络配置的副本，但是在多节点配置中，每个排序服务节点都将拥有自己的网络配置副本。
                </section>

                <section data-markdown>
                    - 网络和通道配置都使用相同的区块链技术保持一致性，这种技术用于用户交易，但也用于配置交易。要更改网络或客户端配置，管理员必须提交一个配置交易来更改网络或通道配置。它必须由适当策略中指定的负责配置更改的组织来签名。这个策略称为变更策略，我们将稍后讨论。
                </section>

                <section data-markdown>
                    - 实际上，排序服务节点操作一个迷你区块链，通过我们前面提到的系统通道连接。使用系统通道排序服务节点分发网络配置交易。这些交易用于在每个排序服务节点上协同维护网络配置的一致副本。以类似的方式，应用通道中的对等节点可以分发通道配置交易。同样，这些交易用于在每个对等节点上维护通道配置的一致副本。
                </section>

                <section data-markdown>
                    - 在Hyperledger Fabric中，通过物理分布式而在逻辑上单一的对象之间的这种平衡是一种常见的模式。例如，逻辑上是单一的网络配置之类的对象，实际上是在一组排序服务节点之间进行物理复制的。我们还看到通道配置、账本以及某种程度上智能合约安装在多个地方，但其接口逻辑上存在于通道级别。这种模式在Hyperledger Fabric中反复出现，使Hyperledger Fabric既分散又易于管理。
                </section>

                <section data-markdown>
                    # 增加另一个节点
                </section>

                <section data-markdown>
                    - 既然组织R3能够完全参与通道C2，那么让我们将其基础设施组件添加到通道中。不是一次只做一个组件，而是我们将一次过添加一个对等节点、它的本地账本副本、一个智能合约和一个客户端应用程序！
                    - 让我们看看组织R3的组件加入后的网络：
                </section>

                <section data-markdown>
                    ![增加另一个节点](images/增加另一个节点.png)
                </section>

                <section data-markdown>
                    - 图中显示了网络N中C1和C2通道的相关情况如下：客户端应用程序A1和A2可以使用C1通道与对等节点P1、P2以及排序服务O4通信；客户端应用程序A3可以使用通道C2与对等P3和排序服务O4通信。排序服务O4可以使用通道C1和C2的通信服务。通道配置CC1应用于通道C1, CC2应用于通道C2。
                </section>

                <section data-markdown>
                    - 首先，请注意，由于对等节点P3连接到通道C2，所以它与使用通道C1的对等节点之间有一个不同的帐本L2。帐本L2有效地作用于C2通道。帐本L1是完全分开的；它的作用域是通道C1。这是有道理的——通道C2的目的是在联盟X2的成员之间提供私有通信，而帐本L2是他们交易的私有存储。
                </section>

                <section data-markdown>
                    - 类似地，安装在对等节点P3上并在通道C2上实例化的智能合约S6被用来提供对帐本L2的受控访问。应用程序A3现在可以使用通道C2来调用智能合约S6提供的服务，以生成可以在网络中每一份帐本L2副本都接受的交易。
                    - 此时，我们有一个单独的网络，其中定义了两个完全独立的通道。这些通道为组织之间的交易提供了独立管理的设施。再者，这是在工作中的非集中化；我们在控制和自治之间取得平衡。这是通过将政策应用于由不同组织控制和影响的通道来实现的。
                </section>

                <section data-markdown>
                    # 加入一个节点到多通道
                </section>

                <section data-markdown>
                    - 在网络开发的最后阶段，让我们回到组织R2上来。我们可以利用R2同时是X1和X2联盟的成员这一事实，来将R2连接到多个通道：
                </section>

                <section data-markdown>
                    ![加入一个节点到多通道](images/加入一个节点到多通道.png)
                </section>

                <section data-markdown>
                    - 图中显示了网络N中与通道C1、C2相关的事实如下：客户端应用程序A1可以使用通道C1与对等节点P1、P2以及排序服务O4通信；客户端应用程序A2可使用C1通道与对等节点P1、P2通信，使用C2通道与对等节点P2、P3以及订购服务O4通信；客户端应用程序A3可以使用C2通道与对等节点P3以及订购服务O4通信。订购服务O4可以利用通道C1和C2的通信服务。通道配置CC1应用于通道C1, CC2应用于通道C2。
                </section>

                <section data-markdown>
                    - 我们可以看到R2是网络中一个特殊的组织，因为它是唯一一个属于两个应用通道的组织！它可以在通道C1上与组织R1进行交易，同时也可以在另一个通道C2上与组织R3进行交易。
                    - 注意对等节点P2如何为通道C1安装了智能合约S5，为通道C2安装了智能合约S6。对等节点P2通过不同账本的不同智能合约同时成为两个通道的完整成员。
                </section>

                <section data-markdown>
                    - 这是一个非常强大的概念——通道既提供了组织隔离的机制，也提供了组织间协作的机制。一直以来，这个基础设施都是由一组独立组织提供的，并且在它们之间共享。
                    - 还需要注意的是，对等节点P2的行为被交易所在的通道控制得非常不同。具体来说，通道配置CC1中包含的策略指示P2在通道C1中进行交易时可用的操作，而通道配置CC2中的策略控制了通道C2中的P2行为。
                </section>

                <section data-markdown>
                    - 同样，这是合适的——R2和R1同意通道C1的规则，而R2和R3同意通道C2的规则。这些规则是在各自的通道策略中捕获的——它们可以而且必须由通道中的每个组件使用，以按照约定执行正确的行为。
                    - 类似地，我们可以看到客户端应用程序A2现在可以在通道C1和C2上进行事务处理。同样地，它也将受适当通道配置中的策略控制。顺便说一句，请注意客户机应用程序A2和对等节点P2使用的是混合的视觉词汇——包括行和连接。可以看到它们是等价的；它们是视觉同义词。
                </section>

                <section data-markdown>
                    # 排序服务
                </section>

                <section data-markdown>
                    - 用心的读者可能会注意到排序服务节点似乎是一个集中的组件；它最初用于创建网络，并连接到网络中的每个通道。尽管我们将R1和R4添加到控制排序节点的网络配置策略NC4中，节点运行在R4的基础设施上。在一个非集中化的世界里，这看起来是错误的！
                </section>

                <section data-markdown>
                    - 别担心!我们的示例网络展示了最简单的排序服务配置，以帮助我们理解网络管理方面的概念。事实上，排序服务本身也可以完全分散的！我们在前面提到过，排序服务可以由不同组织拥有的许多单独节点组成，因此让我们看看如何在我们的样例网络中实现这一点。
                    - 让我们看看一个更现实的排序服务节点配置：
                </section>

                <section data-markdown>
                    ![排序服务](images/排序服务.png)
                </section>

                <section data-markdown>
                    - 多组织排序服务。排序服务包排序服务节点O1和O4。O1由组织R1提供，节点O4由组织R4提供。网络配置NC4为来自组织R1和R4的参与者定义了网络资源许可。
                </section>

                <section data-markdown>
                    - 我们可以看到，这个排序服务完全分散的——它运行在组织R1中，运行在组织R4中。网络配置策略NC4允许R1和R4对网络资源享有同等的权利。来自组织R1和R4的客户端应用程序和对等节点可以通过连接到节点O1或节点O4来管理网络资源，因为这两个节点的行为是相同的，正如网络配置NC4中的策略所定义的那样。在实践中，来自特定组织的参与者倾向于使用其所在组织提供的基础设施，但事实并非总是如此。
                </section>

                <section data-markdown>
                    # 去中心化交易分发
                </section>

                <section data-markdown>
                    - 作为网络的管理点，排序服务还提供了另一个关键设施——交易的分发点。排序服务是一个组件，它从应用程序中收集已背书的交易并将其排序为交易区块，然后将这些交易区块分发给通道中的每个对等节点。在每一个提交节点上，都记录了交易，无论是有效的还是无效的，并且适当地更新了它们的本地帐本副本。
                </section>

                <section data-markdown>
                    - 请注意，排序服务节点O4如何为通道C1充当与网络N不同的角色。在通道级别操作时，O4的角色是收集交易并在通道C1中分发区块。它根据通道配置CC1中定义的策略执行此操作。相反，在网络级别执行操作时，O4的角色是根据网络配置NC4中定义的策略为网络资源提供管理点。再次注意，这些角色分别由通道和网络配置中的不同策略定义。这应该向我们强调Hyperledger Fabric中基于声明性策略的配置的重要性。策略定义并用于控制联盟中每个成员商定的行为。
                </section>

                <section data-markdown>
                    - 我们可以看到，排序服务与Hyperledger Fabric中的其他组件一样，是一个完全分散式的组件。无论是作为网络管理点，还是作为通道中的区块分发者，其节点都可以根据需要在网络中的多个组织中分布。
                </section>

                <section data-markdown>
                    # 变更策略
                </section>

                <section data-markdown>
                    - 在我们探索样例网络的过程中，我们看到了控制系统参与者行为的策略的重要性。我们只讨论了一些可用的策略，但是还有许多策略可以用声明性地定义来控制行为的每个方面。这些单独的策略将在文档的其他部分进行讨论。
                </section>

                <section data-markdown>
                    - 最重要的是，Hyperledger Fabric提供了一个独特的强大策略，允许网络和通道管理员管理策略更改本身!其基本理念是，无论策略变化是发生在组织内部还是组织之间，还是由外部监管机构强制实施，都是一个不变的过程。例如，新组织可以加入一个通道，或者现有组织的许可可能增加或减少。让我们进一步研究如何在Hyperledger Fabric中实现变更策略。
                </section>

                <section data-markdown>
                    - 他们理解的关键点是策略变更是策略在策略内部管理的。变更策略，或简称mod_policy，是管理变更的网络或通道配置中的一级策略。让我们举两个简单的例子，说明如何已经准备好使用mod_policy管理网络中的变更!
                    - 第一个例子是网络最初建立的时候。此时，只允许组织R4管理网络。实际上，这是通过使R4成为网络配置NC4中唯一具有网络资源权限的组织来实现的。此外，NC4的mod_policy只提到了组织R4 -只允许R4改变这个配置。
                </section>

                <section data-markdown>
                    - 然后，我们进化了网络N，以允许组织R1管理网络。R4通过在通道创建和联盟创建的策略中添加R1来实现这一点。由于这种变化，R1能够定义联盟X1和X2，并创建通道C1和C2。R1在网络配置中对通道和联盟策略拥有同等的管理权利。
                    - 但是，R4可以授予R1更多的网络配置权限！R4可以将R1添加到mod_policy中，这样R1也可以管理网络策略的更改。
                </section>
                <section data-markdown>
                    - 第二个能力比第一个强大得多，因为现在R1可以完全控制网络配置NC4了！这意味着R1原则上可以从网络中删除R4的管理权限。实际上，R4将配置mod_policy，也需要R4批准变更，或者mod_policy中的所有组织都必须批准变更。有很多灵活性可以使mod_policy像它所需要的那样精细，以支持所需的任何变更过程。
                </section>

                <section data-markdown>
                    - 这就是mod_policy的工作原理——它允许基本配置优雅地演变成精细的配置。任何时候都是在所有有关组织的一致同意下发生的。mod_policy的行为类似于网络或通道配置中的其他策略;它定义了一组允许更改mod_policy本身的组织。
                    - 在本小节中，我们只讨论了策略和mod_policy的威力。在政策主题中讨论要更长，但现在让我们回到已完成的网络！
                </section>

                <section data-markdown>
                    # 网络彻底建好
                </section>

                <section data-markdown>
                    ![网络彻底建好](images/网络彻底建好.png)
                </section>

                <section data-markdown>
                    - 在这个图中，我们可以看到Fabric区块链网络由两个应用通道和一个排序通道组成。组织R1和R4负责排序通道，R1和R2负责蓝色应用通道，R2和R3负责红色应用通道。客户端应用程序A1是组织R1的一个元素，CA1是其证书颁发机构。注意，组织R2的节点P2可以使用蓝色和红色应用通道的通信设备。每个应用通道都有自己的通道配置，在本例中是CC1和CC2。系统通道的通道配置是网络配置NC4的一部分。
                </section>

                <section data-markdown>
                    - 我们即将结束构建一个样例Hyperledger Fabric区块链网络的概念之旅。我们已经创建了有四个组织的网络，有两个通道和三个对等节点，有两个智能合约和一个排序服务。它由四个证书颁发机构支持。它为三个客户端应用程序提供帐本和智能合同服务，客户端应用程序可以通过这两个通道与它们交互。花点时间浏览一下图表中网络的细节，然后随意地读一遍主题来巩固你的知识，或者去看一个更详细的主题。
                </section>
			</div>
		</div>

		<script src="lib/js/head.min.js"></script>
		<script src="js/reveal.js"></script>

		<script>
			// More info about config & dependencies:
			// - https://github.com/hakimel/reveal.js#configuration
			// - https://github.com/hakimel/reveal.js#dependencies
			Reveal.initialize({
				dependencies: [
					{ src: 'plugin/markdown/marked.js' },
					{ src: 'plugin/markdown/markdown.js' },
					{ src: 'plugin/notes/notes.js', async: true },
					{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } }
				]
			});
		</script>
	</body>
</html>
